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REMARKS 

This amendment is responsive to the Office Action dated January 6, 2010. Claim 8 has 
been amended. Claims 2-5, 7, 9, 10, 14, 16, 17, 23-25, 28, 29, 31, 34-38 and 41 have been 
previously cancelled. Claims 1, 6, 8, 11-13, 15, 18-22, 26, 27, 30, 32, 33, 39 and 40 are pending. 

Claim Rejection Under 35 U.S.C. § 103 

In the Office Action, the Examiner rejected claims 1, 8, 18-22, 26, 27, 30, 39 and 40 
under 35 U.S.C. 103(a) as being unpatentable over Pesce et al. (US 7,328,278) in view of 
Sankaran et a. (US 2003/0231587) and Gaddis et al. (US 7,554,930). In the Office Action, the 
Examiner also rejected claims 6, 1 1 12, 13, 15, 32 and 33 under 35 U.S.C. 103(a) as being 
unpatentable over Pesce in view of Sankaran, Gaddis and Rochberger et al. (US 6,212,188). 

Claim 1 

As an initial matter, Applicant notes that the Examiner rejected claim 1 1 as being 
unpatentable over the combination of Pesce, Sankaran, Gaddis and Rochberger but then makes 
no reference to Rochberger when presenting the rejection against claim 1 1 . Considering that no 
portion of Rochberger was cited in rejecting claim 11, Applicant addresses the rejection of claim 
1 1 as if the rejection were presented based on the combination of Pesce, Sankaran and Gaddis 
rather than the combination of Pesce, Sankaran, Gaddis and Rochberger until such time that the 
Examiner explicitly cites to Rochberger as teaching or suggesting some aspect of claim 1 1 . 

Applicant respectfully traverses the rejections to the extent such rejections may be 
considered applicable to the claims as amended. The applied references fail to disclose or 
suggest the techniques defined by Applicant's claims, and provide no teaching that would have 
suggested the desirability of modification to arrive at the claimed invention. 

Pese, Sankaran and Gaddis 

With reference to independent claim 11, Pesce, Sankaran and Gaddis lack any teaching 
that would have suggested a method comprising, when the number of routes exported from the 
exterior routing protocol process to the interior routing protocol process exceeds an export limit, 
operating the network device in an overload condition in which the network device: (i) updates 
routing information of the interior routing protocol to clear the routes previously exported from 
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the exterior routing protocol, (ii) rebuilds the routing information of the interior routing protocol 
by updating the routing information of the interior routing protocol to associate interior routes 
with a maximum metric that defines a maximum distance from the network device to 
neighboring network devices, and (iii) advertises the updated routing information to another 
network device. 

Thus, according to th language of claim 1 1, the network device enters an overload 
condition upon exceeding an export limit that limits the number of routers capable of being 
exported from the exterior routing protocol to the interior routing protocol. Claim 1 1 requires 
that, after entering this overload condition, the network device updates interior routes to clear, 
(i.e. remove) the routes that were previously exported from the exterior routing protocol to the 
interior routing protocol. Claim 1 1 also requires that, when operating in the overload condition, 
the network device rebuilds the interior routing information to associate the remaining interior 
routes with a maximum metric that defines a maximum distance from the network device to the 
neighboring network device and then advertises this updated interior routing information to 
another network device. For example, as explained in paragraph [001 1] of Applicant's 
specification, by advertising this updated routing information where each interior route is 
associated with the maximum metric, the network device may effectively remove itself from the 
network for purposes of routing within the interior of the network. 

To aid the understanding of how advertising this information may effectively remove the 
network device from the network, consider that other network devices that receive this routing 
information typically respond by performing a process referred to as routing resolution to select 
routes to interior network destinations based on the advertised metrics. By advertising metrics 
associated with a maximum value (i.e., a value sufficient to cause the other network device to 
select routes other than those routes advertised by the overloaded network device) the other 
network devices select alternate routes to the same destinations that avoid the network device) 
"effectively" removes the overloaded network device because the other network devices will 
most likely select the other route. If there is not another route to the same destination, however, 
the other network devices will select the overloaded network device but will do so knowing that 
it may take longer to reach that destination than it normally would. Consequently, should an 
overload condition occur, the techniques set forth by claim 1 1 provide a form of graceful failure 
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that allows the overloaded router to provide limited routing functionality for routes that require 
use of the router. 

The combination of references fails to provide any teaching to suggest these aspects of 
Applicant's claim 1 1 . Pesce teaches to a system that allows routing information stored to a first 
routing database to be exported to a second routing database in accordance with stored route 
mapping information. 1 Pesce describes one example of applying this route mapping information 
in column 3, lines 23-28 in which the stored route mapping information is used to export "said 
routing information from a first routing database ... of the first routing source, e.g., the OSPF 
protocol, and [import] it into a second routing database ... of a second routing source, e.g.., the 
BGP protocol." The OSPF protocol is often considered an interior routing protocol, while BGP 
is often considered an exterior routing protocol. Pesce further indicates that this system may 
employ blocking information that "identifies at least one couple of routing sources . . . and 
overrides the routing mapping information." 2 Pesce explains that this blocking information is 
useful "in order to leave to the operator the possibility of blocking some kind of mapping in 
particular operating conditions of the network." 3 

Pesce suggests that each rule in a table that stores the route mapping information, where 
such rule is referred to an entry in a set rule table, comprises information relating to at least a 
metric value and a metric scale. 4 Pesce, however, provides little clarification as to what this 
metric represents. In column 9, lines 17-25, Pesce indicates that a lower metric value is to be 
used for a metric filter, where "[i]n order to match, routes must have a metric value higher or 
equal to the value reported in this field." 

In rejecting the aspect of claim 1 1 directed to rebuilding the routing information of the 
interior routing protocol by updating the routing information of the interior routing protocol to 
associate interior routes with a maximum metric that defines a maximum distance from the 
network device to neighboring network devices, the Examiner suggests that the metric associated 
with the rules of the route mapping information is the same as Applicant's maximum metric that 
is associated with the routing information of the interior routing protocol, which is clearly 
improper. Pesce explicitly teaches that this metric value is associated with the route mapping 



1 Abstract. 

2 Column 4, lines 52-59. 

3 Column 4, lines 59-61. 

4 Column 5, lines 15-18. 
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information, not the routing information. Moreover, Pesce does not actually describe updating 
this metric, but even assuming Pesce does mention updating this metric, Pesce would update a 
metric associated with route mapping information, which is substantially different from the 
Applicant's claim 1 1 that requires rebuilding the routing information of the interior routing 
protocol by updating the routing information of the interior routing protocol to associate interior 
routes with a maximum metric that defines a maximum distance from the network device to 
neighboring network devices. 

Moreover, Pesce provides for blocking information that blocks the exportation of certain 
routes during the exportation process. This blocking information however does not update 
routing information of the interior routing protocol to clear the routes previously exported from 
the exterior routing protocol, as required by claim 1 1 . That is, Pesce provides a mechanism to 
prevent the exportation of certain routes but this blocking information does not clears routes 
previously exported. Consequently, Pesce does not teach or suggest update routing information 
of the interior routing protocol to clear the routes previously exported from the exterior routing 
protocol, as required by claim 1 1 . 

Neither Sankaran nor Gaddis teach or suggest these aspects of Applicant's claim 1 1 and 
thereby cure the deficiencies noted above with respect to Pesce. Consequently, the combination 
of references lack any teaching to suggest rebuilding the routing information of the interior 
routing protocol by updating the routing information of the interior routing protocol to associate 
interior routes with a maximum metric that defines a maximum distance from the network device 
to neighboring network devices and updating routing information of the interior routing protocol 
to clear the routes previously exported from the exterior routing protocol, as required by 
Applicant's claim 11. 

In rejecting Applicant's claim 1 1, the Examiner only relies on paragraphs [0035] and 
[0045] of Sankaran for its teaching regarding what the Examiner characterizes as maintaining a 
count of routes exported and rejecting additional routes exported when the count exceeds the 
export limit set by the command. Paragraph [0035] of Sankaran discloses a threshold that 
triggers different discard algorithms. In this sense, paragraph [0035] of Sankaran provides for 
"threshold-specific discard algorithms" that are applied once certain storage thresholds are 
reached. Consider the example set forth in this portion of Sankaran, which provides that "once a 
threshold (e.g., a first threshold) is reached, a threshold-specific algorithm is applied . . . [and] 



11 



Application Number 10/687,989 

Response to Office Action mailed January 6, 2010 

once another threshold (e.g., a second threshold) is reached, another threshold-specific discard 
algorithm is applied." According to this portion of Sankaran, the thresholds are defined in terms 
of a percentage of a storage capacity available to store routing information and the threshold- 
specific discard algorithms apparently remove redundant routes from the route table. Paragraph 
[0045 of Sankaran reiterates various teachings of paragraph [0035] in operation with respect to a 
particular example . 

Yet, these cited portions of Sankaran do not teach or suggest rebuilding the routing 
information of the interior routing protocol by updating the routing information of the interior 
routing protocol to associate interior routes with a maximum metric that defines a maximum 
distance from the network device to neighboring network devices, as required by Applicant's 
claim 11. In this respect, Sankaran does not cure the deficiencies of Pesce noted above. 

In addition, the portions of Sankaran relied on by the Examiner to reject claim 1 1 fail to 
even so much as suggest other aspects of claim 1 1 . For example, the portions of Sankaran relied 
on by the Examiner refer to thresholds defined in terms of a percentage of a storage capacity, 
which is substantially different from an export limit that limits the number of routes exported 
from the exterior routing protocol process to the interior routing protocol process in the manner 
required by Applicant's claim 1 1 . 

As another example, Sankaran culls the routing table to remove redundant routes (i.e., 
duplicate routes) as noted by paragraph [0035], which is substantially different from updates 
routing information of the interior routing protocol to clear the all of the routes that were 
previously exported from the exterior routing protocol such that only interior routes remain, as 
required by Applicant's claim 1 1 . That is, the threshold-specific discard algorithm of Sankaran 
makes no distinction between routes previously exported from the exterior routing protocol and 
interior routes learned via the interior routing protocol when culling routes in contradiction to the 
explicit requirements of Applicant's currently amended claim 1 1 . 

Likewise, Gaddis does not cure the deficiencies of Pesce or Sankaran noted above. 
Gaddis is silent with respect to rebuilding the routing information of the interior routing protocol 
by updating the routing information of the interior routing protocol to associate interior routes 
with a maximum metric that defines a maximum distance from the network device to 
neighboring network devices, as required by Applicant's claim 11. In fact, Gaddis as noted 
below defines a prefix size limit to exclude routes from being injected, but fails to mention any 
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process whereby routing information of an interior routing protocol is rebuilt after the routes 
have already been injected. Moreover, Gaddis does not teach or suggest an export limit that 
limits the number of routes exported from the exterior routing protocol process to the interior 
routing protocol process in the manner required by Applicant's claim 1 1 . 

According to the Examiner, neither Pesce nor Sankaran teaches a user-defined size 
threshold, but column 17, lines 29-34 of Gaddis teach what the Examiner characterizes as a 
prefix limit that may be set for injected routes. According to the cited portion of Gaddis, what 
the Examiner characterizes as a "prefix limit" is in fact a size limit that "may be placed on the 
prefix/mask to limit the volume of injected routes that will be used." The prefix/mask discussed 
in this portion of Gaddis refers to an address prefix or IP address mask and the size limit 
discussed in this portion of Gaddis refers to a limit on the size of the prefix/mask. Defining a 
limit on a prefix/mask is substantially different than defining an export limit that causes the 
network device to enter an overload condition in the manner required by Applicant's claim 11. 
Consequently, Gaddis does not cure this deficiency of Sankaran noted above. 

In summary, Pesce teaches to exporting routes between route tables maintained by 
different routing protocols, one of which may represent an exterior routing protocol while 
another represents an interior routing protocol. The Pesce system describes route mapping 
information to effect the exportation of routing information from the exterior routing protocol to 
the interior routing protocol. The route mapping information includes rules that are stored as 
entries to a set rule table, each of which may be associated with a metric value and a metric 
scope. Sankaran describes a system that provides for storage capacity thresholds, which when 
reached trigger a corresponding one of a plurality of different threshold-specific discard 
algorithms. The threshold-specific discard algorithms cull redundant routes regardless of 
whether such routes represent routes exported from the exterior routing protocol to the interior 
routing protocol. Gaddis then provides teachings for a defining a size limit that limits the size of 
a prefix/mask. 

The combination of Pesce and Sunkaran results in a system capable of defining a 
threshold and a threshold-specific discard algorithm that limits the exportation of routes from the 
exterior routing protocol to the interior routing protocol based on a storage capacity available to 
store routes by the interior routing protocol. Further combining Gaddis with this Pesce/Sankaran 
system results in a system that enables the definition of this threshold as a size limit placed on 
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the prefix/mask. Applicant is unsure as to how this combination may produce any feasible 
result. Consequently, Applicant presumes that the Examiner cites Gaddis only for its suggestion 
that such thresholds may be user defined. 

Even with this assumption in mind, the Pesce/Sunkaran/Gaddis system only enables 
thresholds to be defined that invoke a threshold-specific discard algorithm that culls routes 
regardless of whether these routes constitute exported routes or not. That Pesce enables metrics 
to be associated with the route mapping information and that routes can be blocked using 
blocking information seems irrelevant considering that the metric required by Applicant's claim 
1 1 is defined for actual routing information, not route mapping information, and the update of 
the routing information once the network device enters the overload condition is to clear routes 
previously exported, as noted above with respect to Applicant's claim 11, not block the 
exportation of routes. 

In this respect, the combination of Pesce, Sankaran and Gaddis fails to teach or suggest 
the method of Applicant's claim 1 1 comprising, when the number of routes exported from the 
exterior routing protocol process to the interior routing protocol process exceeds an export limit, 
operating the network device in an overload condition in which the network device: (i) updates 
routing information of the interior routing protocol to clear the routes previously exported from 
the exterior routing protocol, (ii) rebuilds the routing information of the interior routing protocol 
by updating the routing information of the interior routing protocol to associate interior routes 
with a maximum metric that defines a maximum distance from the network device to 
neighboring network devices, and (iii) advertises the updated routing information to another 
network device. 

Independent claims 1, 8, 18, 27 and 33 

With regard to independent claims 1,8, 18, 27 and 33, the applied references fail to teach 
or suggest each and every limitation recited by these independent claims for at least one of the 
reasons noted above with respect to claim 1 1 . For example, Pesce, Sankaran and Gaddis fail to 
teach or suggest updating routing information to associate the routes with a maximum metric that 
defines a maximum distance from the network device to neighboring network devices when the 
count exceeds the export limit, as required by applicant's claim 1 . As noted above, none of these 
references teaches or suggests a maximum metric that defines a maximum distance from the 
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network device to neighboring network devices. Pesce's reference to a metric value and scope, 
again as noted above, falls short of the metric required by claim 1 in that the Pesce metric value 
refers to a metric associated with route mapping information not actual routing information. 
Sankaran and Geddis do not cure this deficiency of Peske. Consequently, the applied references 
to not teach this aspect of claim 1 . 

As another example, the applied Pese, Sankaran and Gaddis references fails to teach or 
suggest maintaining respective counts of routes exported from an exterior routing protocol 
executing on the network device to each of the instances of the interior routing protocol 
executing on the network device, as required by currently amended claim 8. Instead, Sankaran 
only teaches to a storage capacity threshold, which is substantially different from maintaining 
respective counts of routes exported form an exterior routing protocol, as required by claim 8, as 
amended. To illustrate the difference, consider that Sankaran thresholds would not discriminate 
between exported routes and routes learned using the internal routing protocol as both would add 
routes that increase the amount of memory or storage consumed. In comparison, Applicant's 
currently amended claim 8 requires maintaining counts of routes exported from an exterior 
routing protocol, which is substantially different from the thresholds described by Sankaran. 
Consequently, the applied references to not teach this aspect of claim 8, as amended. 

To the extent independent claims 18, 27 and 33 recite limitations similar to those 
referenced above with respect to claims 1, 8 and 1 1, the arguments made above apply to these 
independent claims 27 and 33 and to the claims that depend from claims 1, 8, 1 1, 18, 27 and 33. 

Rochberger 

With respect to the additionally cited reference, Rochberger, the Examiner appears to 
only rely on Rochberger in rejecting claims 6, 1 1 12, 13, 15, 32 and 33 to teach or suggest setting 
an overload bit upon a network device entering an overload status. The portions relied on by the 
Examiner in rejecting these claims however fail to cure the deficiencies noted above with respect 
to the combination of Pesce, Sankaran and Gaddis. The combination of Pesce, Sankaran and 
Gaddis therefore fails to teach or suggest the techniques defined by Applicant's claims. 



15 



Application Number 10/687,989 

Response to Office Action mailed January 6, 2010 

For at least these reasons, the Examiner has failed to establish a prima facie case for non- 
patentability of Applicant's claims 1, 6, 8, 11-13, 15, 18-22, 26, 27, 30, 32, 33, 39 and 40 under 
35 U.S. C. 103(a). Withdrawal of this rejection is requested. 



CONCLUSION 

All claims in this application are in condition for allowance. Applicant respectfully 
requests reconsideration and prompt allowance of all pending claims. Please charge any 
additional fees or credit any overpayment to deposit account number 50-1778. The Examiner is 
invited to telephone the below-signed attorney to discuss this application. 

Date: May 6, 2010 By: /Matthew K. Gage/ 

SHUMAKER & SIEFFERT, PA. Name: Matthew K. Gage, Reg. No.: 63,059 

1625 Radio Drive, Suite 300 
Woodbury, Minnesota 55125 
Telephone: 651.286.8367 
Facsimile: 651.735.1102 
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